INFO-ATARI16 Digest Wed, 6 Dec 89 Volume 89 : Issue 763 Today's Topics: C question Form Doc's Spectre & Adobe Type Manager SS -> DS drive upgrade STOS Basic What does the read-only bit mean? What Kermit/UNITERM bugs? (2 msgs) ---------------------------------------------------------------------- Date: 6 Dec 89 20:12:57 GMT From: cscnj!pat@rutgers.edu (Patrick Hester) Subject: C question Message-ID: <564@cscnj.csc.COM> In article <875@lzaz.ATT.COM>, hcj@lzaz.ATT.COM (HC Johnson) writes: + In article <8912050802.AA12717@ucbvax.Berkeley.EDU>, S61304@PRIME-A.POLY-SOUTH-WEST.AC.UK (Rat) writes: + > + > Why wont Sozobon, Lattice or any other C compiler I've tried compile the + > following, from K&R? + > + > main() + > $ + > char fred[] = "Some string constant"; + > + > + > + > This has been confusing me for a while, as K&R (surely correct!) would + > seem to indicate that this is indeed permissible! + + NO NO NO + + you can have char *fred[] = "hello"; + or + char fred[] = ?'h','e','l','l','o','\0'?; + + but not + char fred[] = "hello"; yes you can. it sets up an array of chars including a null. fred then refers to the address of the first byte in the array and fred[n] is one char. you usually can't do this, tho, inside a function unless you declare it static. Also, it's gotta be before any program instructions on most compilers. -- "We've all been used 8=8 made loud to play loud and reused..." --<-@ "And abused." =8(/\/) rutgers!cscnj!pat "And amused!" 8=======8 (201)-562-6533 ------------------------------ Date: 6 Dec 89 03:46:06 GMT From: davidli@UMN-CS.CS.UMN.EDU (David Paschall-Zimbel) Subject: Form Doc's Message-ID: <17468@umn-cs.CS.UMN.EDU> In article <473eecf4.14a1f@force.UUCP> covertr@force.UUCP (Richard E. Covert) writes: >Hey, it doesn't seem like many folks like the TeX docs to form. Might be because they didn't have any idea what to do with the .DVI file. Of course, if you're receiving comp.sys.atari.st, then it's fairly likely that you have access to a .DVI driver AND a laser printer, like I did. The docs are quite beautiful when printed on a laser printer. So, at least ONE person liked the documentation. >Must be some form of Elitest mentatlity to post docs to a program >in a format that 99% of the people don't use. Must be some form of Elitist mentality to DEMAND documentation to a program be put up in a manner convenient to _them_. The program didn't _HAVE_ to be posted in the first place. Would you have been happier if that was the case? If not, I'd suggest you take your 'Elitist' mentality and go somewhere else. >Hey, if you are good enough you will have TeX, right? :-) For the information of All Concerned. You do not need the entire TeX release to process a .DVI file. You need a .DVI driver (at our humble little site I have access to a DVItoPostScript and a DVItoLN03 driver), the requisite fonts and a printer. Heck, you could even use the DVItoEpson driver that's available via ftp. Most everyone who has access to network news has access to TeX, if they really wanted to take the time to find out... -- David Paschall-Zimbel ------------------------------ Date: 6 Dec 89 20:17:19 GMT From: brunix!iris.brown.edu!mjv@uunet.uu.net (Marshall Vale) Subject: Spectre & Adobe Type Manager Message-ID: <22321@brunix.UUCP> We just received Adobe Type Manager and of course I quickly installed it on my Spectre GCR system to see if it worked. First, a little background. Adobe Type Manager replaces the way the Mac displays fonts on screen. Noramlly, the Mac uses bitmaps that are installed into the system. To get a nice looking font on the screen, you need to have that particular size installed for it to look nice. If you don't, then the Mac's QuickDraw routines will try to scale it and most often, it looks very, very ugly. ATM catches all those font scallings and uses its own outline fonts to create nice, clean fonts in any size. This is very important for both the screen and ImageWriter (or other dot matrix and QuickDraw printers) in that all the fonts will scale smoothly. My system is a Mega2 with a ICD host adapter and Seagate 277R 65 meg HD and the Spectre GCR. The ATM disk contains the ATM INIT (an auto file) and a control panel document (Cdev). There are two inits, one for the 68000 Macs and one for the 020/030 Macs; we, of course, use the 68000 one. The disk also contains the outline font files for 4 fonts and their bitmap fonts. For the ATM to work, you also need at least one bitmap size font installed, the more the better(10 and 12 is a good minimum). You can turn ATM on or off from the control panel and boot up in case an application will not work with it. Here are some interesting figures I found after using ATM for a bit. Installing ATM and all the outline fonts files for the all the fonts in a LaserWriter + (Avante Garde, Bookman, Courier, Helvetica, Narrow Hel., New Century Schoolbook, Palatino, Symbol, Times, Zapf Chancery, Zapf Dingbats), took up about 1,350K on my HD. Note: I already had the bitmaps for the fonts installed before ATM, your mileage will vary.) The amount of memory that I had decreased by 200K. 100K is needed for ATM and a minimum of 64K in needed for a font cache (you can set this). The font cache holds the data for some of the scalled fonts that you have done. If you use a font that has been previously scalled and is in the cache, it appears instantaneous. The large the cache, the faster the scales are. The scales themselves are very fast if you consider what it is doing. Generating a 33 or 57 point size for example, took only a few seconds with wonderful results. The larger the point size, the longer it will take. I tested ATM with Word 4, MacWrite 4.6, MacDraw II 1.0, MacDraw 1.9.5, both SuperPaint versions, and WriteNow 1.0. All worked. ATM is a serious memory hog. 1meg users might want find that some of their programs no longer run in so little room (about 600K). I don't know if disabling ATM will help. However, it might be just your cup of tea since it will do very nice results on QuickDraw printers such as dot matrix printers, QuickDraw laser printers and the QD DeskJet. BTW I didn't have time to check it out with my printer (Star NX-10) and Epstart 2.5 (Epson printer driver) but I will report on that in a bit. Hope you find this useful. -- mjv@iris.brown.edu "And, oh! Father Christmas, if you love me at all, Bring me a big, red india-rubber ball." A.A. Milne "Now We are Six" ------------------------------ Date: 6 Dec 89 03:09:43 GMT From: rochester!rit!ultb!clf3678@louie.udel.edu (C.L. Freemesser) Subject: SS -> DS drive upgrade Message-ID: <1699@ultb.isc.rit.edu> In article <22194@brunix.UUCP> mjv@iris.brown.edu (Marshall Vale) writes: > > I have two friends who both have SS drives and would like to upgrade to DS >drives. One has an old SF 314 with a corner button eject and the other >has a 520STfm. > >1. What is a reliable and cheap DS drive to buy as a replacement? Netters > have mentioned a Toshiba model several times. Toshiba is a good choice. There are others, but the Toshiba is widely available, and as cheap as $68 or so. >2. Are there any hardware changes that need to be made? For example, if > it can't normally recognize media changes. I really don't think so. The circuitry in both the external drive (the PCB board) and in the STfm should take care of the media change problem. If they do not, simply run a jumper between pins 2 and 28 of the drive's 34 pin card edge. However, you might have a problem with the cables. Depending on where the connectors on the new drive (with respect to the old one) are located, you might have to wire up some cable extensions. >3. What is a good price for that drive and suggested place to purchase > from? Pay no more than $85 or so for a Toshiba. Try to get an ND-354 or an ND-352-A. The 352-A, if I remember correctly, only requires the +12V line. If so, be sure to cut the +5V line coming from the circuit board. >4. Any suggestions as to what to do with the old drive. Use it as a doorstop? Seriously, just hold onto it. Never know when you might need it. > Thanks for you're kind attention. > > BTW, one of these SS drive persons actually has the Atari color monitor >with disk drive built it (PS 300 or PS 3000)! If you plan on upgrading that PS-3000, be sure that drive has PLENTY of shielding around it. That CRT will play havoc on it. Chris Freemesser, Rochester Institute of Technology :BITNET:%clf3678@RITVAX ||| ____________ :GEnie: C.FREEMESSER ||| /___ / (and 8-bit too!) :USENET: clf3678@rit.isc / | \ ______/ / : .edu Call the A.C.O.R.N BBS (716)436-3078, 300/1200 baud :<-or my BBS ------------------------------ Date: 5 Dec 89 21:36:19 GMT From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher) Subject: STOS Basic Message-ID: <1862@atari.UUCP> david@bdt.UUCP (David Beckemeyer) writes: | In article larserio@IFI.UIO.NO (LarsErikOsterud) writes: | >One of my friend has STOS and TOS 1.2 but we tried it on my MEGA4 with | >TOS 1.4 - It worked OK, BUT you can't move the mouse-pointer !!!!! | Applications generated with STOS seem to exhibit this same behavior. This is because STOS used absolute, undocumented memory locations for mouse position. More's the pity, because a legal way of getting at these variables _is_ documented. A couple of other software packages exhibited this behaviour in Rainbow TOS testing here at Atari, as well. I believe Antic has a new version of STOS that works better with Rainbow TOS. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 5 Dec 89 19:23:23 GMT From: fox!portal!atari!apratt@apple.com (Allan Pratt) Subject: What does the read-only bit mean? Message-ID: <1861@atari.UUCP> VBRANDT@DBNUAMA1.BITNET writes: > As most of you know there is a bit in the attribute byte that indicates >READ-ONLY status when it's set. This means that the file can't be written >to, can't be renamed or deleted. > BUT: I can change the time/date entry with Fgsdatim() (or whatever the >GEMDOS function is called). Is this a bug or a feature?? Or is it necessary >to enable the desktop to retain the time/date stamp while copying read-only >files? Well, here's the logic behind it: setting the read-only bit means you can't change the DATA IN THE FILE. You can still change the file's directory entry, which includes its date and time. This is necessary because you must be able to change the file's attribute byte, also in the directory. If you couldn't do that, you couldn't ever un-write-protect the file. Alternatively, the answer is, "Because that's how Jason Loveman implemented it." It's not likely to change. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt ------------------------------ Date: 4 Dec 89 17:00:34 GMT From: cs.yale.edu!fischer-michael@CS.YALE.EDU (Michael Fischer) Subject: What Kermit/UNITERM bugs? Message-ID: <7477@cs.yale.edu> In article <89337.135453SML108@PSUVM.BITNET> SML108@PSUVM.BITNET writes: >On the subject of kermits and ST's... > >I also use the Uniterm Kermit to transfer to and from my ST. it works fine wit >h VAX computer systems, however weird, VERY WEIRD stuff happens with Unix sys- >tems, both System V and 4.3bsd. It works fine transferring text files, but >gives a potpourri of errors with binary files. This DOES NOT HAPPEN ON VAXES! > Ther really weird bit about the erros is that if you set the maximum allowabl >e number of erros high enough, it eventually succeeds in transferring the block >s it has trouble with. I have no idea why this happens..... > >Has anyone else figured this one out... > >Scott Le Grand aka SML108@PSUVM.PSU.EDU I have no trouble at all with either text transfers or binary transfers between Uniterm Kermit on my ST and C-Kermit running on a 4.3bsd system (a Sun Sparcstation). You do have to remember to set binary mode at both ends for binary transmissions. I usually say "kermit -ix" to the Unix kermit, click the "binary" box on the Uniterm menu, and use the "get" or "put" command. ================================================== | Michael Fischer | | Arpanet: | | Bitnet: | | UUCP: | ================================================== ------------------------------ Date: 5 Dec 89 08:52:46 GMT From: mcsun!cernvax!ethz!chx400!ugun2b!ugobs!bartho@uunet.uu.net (PAUL BARTHOLDI) Subject: What Kermit/UNITERM bugs? Message-ID: <467@obs.unige.ch> In article <8912010813.AA04349@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg Csullog) writes: > One netter mentioned problems with UNITERM's Kermit. ... > The ONLY Kermit I trust is UNITERM's so WHAT problems are there? I can confirm that I do use UNITERM (2.0e) Kermit almost dayly in binary mode with the following counterparts : Vax-vms Kermit32, Vax-vms CKermit, IBM vm-cms Kermit, Sun unix Kermit and PC Kermit 2.32 . My Atari 1040ST is connected at 19.2 Kbps to an Ethernet pad (Bridge cs/100) with XON/XOFF protocol. The line to the IBM goes through the vax, then through a x.25 line to a central pad that connects me to the 3090 ... From experience, I have set the packet length to 1024 (reduced to 96 max by CKermit ...) and use the CRC for error detection. Depending on various conditions I get no errors or a few retries, but never got locked or with unreadable file (even a single error would be rejected by the dearcing programs). The mean transfer rate is almost 1KB/s with the Vax (780), while it's almost 4 times slower with the IBM due to the many intermediates nodes, but the error rate is similar. I found the 1KB packets giving the best throughput. A 2KB is even better, but only if the retries are very rare. I never the less remember a discussion about a year ago (or more ?) between Simon Poole and ? concerning binary transmission. After reading all arguments, i was convinced that UNITERM worked the right way, although the documentation could have been interpreted differently. The fact that I never had any problem with the 5 different versions above confirms this 'experimentaly' I think (not a proof !) regards and Thanks to Simon if he reads this ! Paul ---------------------------------------------------------------- | Dr Paul Bartholdi bartho@cgeuge54.bitnet | | Observatoire de Geneve bartho@obs.unige.ch | | 51, chemin des Maillettes 02284682161350::bartho (psi) | | CH-1290 Sauverny 20579::ugobs::bartho | | Switzerland +41 22 755 39 83 (fax) | | +41 22 755 26 11 (tel) | | +45 419 209 obsg ch (telex) | ---------------------------------------------------------------- ------------------------------ End of INFO-ATARI16 Digest V89 Issue #763 *****************************************